一个银行科技人的思考：我们要能守成，但更懂变通 | 2020年度策划
又是一季风云幻过，
趋势似乎在遥远的地方，
却又总是好像随风而至。twt社区邀请同行中冷静睿智的观察者，把他们各自感悟到的岗位趋势告诉我们，让每个社区同行都能知己知彼地度过2020这一年。
twt 社区出品
第21期
【作者】社区ID：skey_deng，就职某农村商业银行，本人从事IT工作已经10个年头，围绕IT工作先后从事综合布线、软件开发、软件实施、软件项目建设、数据中心硬件建设、数据中心运维、科技架构规划等多项工作。
综述
随着国民经济的繁荣发展，我国的社会主体经济由第一产业、第二产业重点向第三产业类型转变，作为国家钱袋子的银行业也已经开始转变，股份制银行做大做强，市联社纷纷转变为股份制银行，越趋强调竞争力，对外通过多样化、符合市场需求的产品抢占市场份额，对内通过严审成本投入、高效管理等策略控制企业成本。
互联网金融的出现更加剧了市场征战，传统金融面临着不变则亡的困局，各银行纷纷借鉴互联网金融模式，以“稳中求变”的原则保持市场竞争力。在此局面下，银行科技也面临着稳定、发展、变通、提升的要求。
传统银行要求
传统银行科技要求的是稳定，安全，“全年零事故”是我们行领导对我们不变的要求，因此在规划科技架构时，以“稳定、安全”为第一要务，核心系统必须架设在以IBM为代表的国外小型机上，存储必须使用以EMC为代表的国外存储上，数据库必须使用以Oracle为代表的国外商业数据库软件上，这样的软硬件架构也确实稳定，IBM的小型机在我行使用了5年，只在今年扩容内存时，因为重启坏了两块FSP卡；EMC的存储在5年中也仅仅更换了4个电源模块，20几块硬盘；Oracle数据库只要你写的SQL语句不是特别烂，也很少出错，而且在原厂强大的支撑下，可以指导、优化产品，使业务处理更加流畅，是真的稳。
传统银行架构弊病及新形势应对方案
IOE的架构其成本投入是非常高昂的，比如1台半配的IBM小型机可以买10几台X86服务器，1台EMC存储的成本投入，在使用分布式存储架构后，容量可以10倍提升。分布式架构可以采用X86设备作为主计算资源及存储资源，这样保证计算和存储能力的同时，大大降低设备购置成本。
再有其横向扩容能力也是有限制的，即使你牺牲性能也无法得到提升，但是分布式存储的扩展能力是非常优越的，通过其横向扩展能力大大提升容量。
再有其纵向扩展能力受限于硬件，比如数据库想要提升性能，除了SQL语句的优化处理外，更需要其承载的设备有更优的CPU处理能力，更多的内存，而目前市场的CPU芯片处理能力貌似已经达到一个趋于稳定的态势，个人了解2015年后，X86的CPU芯片基本都是4.2GHz以下的主频，一般也以4路为主，变动较小。
再有数据类型发生变化，数据量处理要求越来越大，数据库无法处理或者处理的非常低效，比如Oracle数据库是关系型数据库，无法处理非结构化数据，而当前社会所产生的数据却越来越多的是非结构化数据。非结构化数据库、大数据平台的出现可以处理海量的非结构化数据。
科技发展中工作共性方法
科技技术没有原地踏步，“云生态”、大数据、分布式架构、去IOE、超融合、人工智能、超融合等等名词携带着其技术体系滚滚而来，作为一个搞IT的，没有听说过这些名词那么真是罪大恶极，不配为一个IT人员，甚至街道里下象棋的大爷也能跟你说上一嘴“现在是大数据时代”，当此之际，银行科技又需要怎样的转变？以下是一个普通员工的喃喃自述，以抛砖引玉。
准确定位
我得说兄弟，你活该屈才，你了解过你们银行在辖区内的业务定位吗？你了解你们银行的发展战略吗？你理解到什么程度？
我的领导曾经告诉我“屁股决定脑袋”，当他坐在领导的那个位置的时候，先天就比你有更多的机会了解当前企业的一些状况，了解更多的行级决定，行内当前阶段的重点是开拓哪部分的业务，需要引进什么样的系统，需要怎样控制成本，需要朝哪个大方向发展，这种架构引进后所能开展的业务是否受到本行监管评级的约束？所以他们想到的更多。
所以你要做的是什么？了解领导想要的，了解行内业务发展重点在哪里，了解发展行内重点发展业务所需要的技术体系，从而去采用适应的技术，设计合理的架构，明确方向，准确定位。
精准核算成本
你看哪哪银行都开始数字化转型了，上了1000+节点的分布式架构，我们行也上吧，我们也做数字化转型，我们也上分布式架构，领导不批，这领导傻的吗？不知道新技术能够提升业务系统的应对能力，可以开展好多种业务的啊，而且符合我们行的发展战略，其上能开展的业务符合我行的市场定位，我们的监管评级水平允许我们开展此类业务，能赚钱的啊，跟着这么个领导，真的烦啊！
兄弟，您核算过成本吗？好的技术一定适合自己的银行吗？
“我不管了，我只是一个做技术的，我哪管那么多，我只知道技术好用就行，我对技术了解的通透无比……”
那么我要是作为你的领导我也对你say no，我按照你的设计，引进并落地实施了分布式架构，新业务开展后每年的盈利仅仅是1、2千万，新架构的投入却是5、6千万，每年还要搭进去上千万的维护费用，我傻的吗？我得多少年才能把投入赚回来？银行的股东都傻吗，拿钱陪你玩技术？
所以你即使找准了行内的发展定位，也要考虑新技术体系、新设计架构落地所产生的成本。比如当前智能手机非常普及，50、60岁的大龄人群也基本人手一个智能机，更别提30、40岁左右的人，他们有更加好的经济基础，更加善用有效的资金产生更多的收入，那么我们设计手机银行的信贷业务，引入各种个人、对公的信用贷款，这就需要发展手机银行应用，而此类应用可以在传统的IOE架构中运行，也可以采用新的分布式架构上运行，我们怎么去抉择？
如果我们是国有大行或者分行开到全国各地乃至海外的股份制银行，按照32个省份，每个省份每年因新业务上线增加的平均贷款额为10亿，在6.5%左右的贷款利率情况下，每年所产生的利润将是20.8亿，那么上一个5、6千万的项目，仅仅是利润额的零头，为什么不上？
新技术好，新技术带来了新的发展，抢占了市场份额，有利益，行内领导肯定做。但如果我们仅仅是一个地区农商行，我市每年因新业务上线增加的贷款额为1亿，利率是按照国家规定的上下浮动，也在6.5%左右，那么每年的利润仅仅是650万，您让我上一个5、6千万的项目，你想赔死我？当然我上面列举的数字不太准确，但是也表述了现象，我们常说“吃饭、穿衣量家底”就是如此了。
新形式下工作转变
以上其实无关新旧架构体系，只是一般工作做法而已，那么在新旧架构体系更迭的当前，我们面临我们需要做怎样的转变？
科技思维升华
传统银行求稳定，求安全，毕竟银行的安全稳定关乎国计民生，银行的系统如果故障很容易引发社会动荡，比如挤兑等，所以传统银行的架构设计就突出一个“稳”字。
以前银行有国家扶持，没有互联网金融，老百姓有钱先想着存银行，个人、企业想用钱，只能找银行贷款，而且地区限制严重，你爱存不存，爱贷不贷，我就这么多业务，不满意你就不要来，国有银行门槛那么高，你搞不起，剩下这片就我能给你贷款，存钱了，所以银行大部分都盈利，只要不发生长时间的系统宕机，不引发政治事件，可以了，其银行科技系统架构也就没有太多的变化性要求，系统十几年如一日的不变，硬件架构稍稍增补也就够了，科技人员只要保障当前系统平稳运行可以了。
但是现在不行了，互联网金融的出现，打破了地域限制，老百姓的钱可以存在各类互联网金融产品中，收益比银行存款高，取现灵活；而又可以通过各类信用贷款获取必要的资金支持，我不去你银行贷款了，更加方便的是互联网金融的处理速度更快，我不必到银行排队。
那么银行就要适应市场要求，开设亲民、便民的产品，相对应的科技架构体系也要适应各类业务开展需求，稳定不是唯一的衡量指标，科技人员要设计更加高效的架构体系。
新形势下工作需求
文中仅仅讲述一方面而已，而实际上当前对银行的架构体系要求更高，要能够处理更大规模的数据，包括关系型数据和非关系型数据；要适应高并发量、低响应延迟的需求；要响应业务需求快速变动，业务系统快速迭代的需求等等，这都需要科技人员从“稳定、安全”的思维模式中升华，稳定安全不代表一成不变，不同的业务需求中，安全稳定的比重需要衡量。
既然说思维升华，那么当前的业务形式又面临哪些具体的问题？
降低成本要求
银行受到互联网金融的冲击，存取款业务、信贷业务等被分蛋糕，纷纷从国有制、集体制分离出来，成立股份制银行，那么入股的股东就更看重利益，对外提升盈利，对内进行成本控制，科技作为消费部门，其投入更被严格把控，一台小型机3、5百万，1台存储3、4百万的投入不是没有，而对于中小行来说投入不可谓不大，而当前炒的火热的重要业务下移X86正是因此而起，X86设备的性能虽对比同配小型机仍略有不如，但是在业务系统支持负载、集群模式部署的情况下，已经不会成为限制业务并发、响应需求的瓶颈，而且X86的稳定性也有所提高，并且有多冗余的情况下，大大降低了安全风险发生的几率，对比价格更是十分之一的低廉，为什么不使用？既迎合企业降低成本要求，又满足安全稳定运行需要。
由此及彼，分布式存储的使用也能大大解决视频、影像、文本文件等的大容量存储需求，并且控制成本。
快速迭代要求
谁先占有市场，谁就能盈利，在当前的互联网通信飞速发展的时代，人民获取信息的渠道增多、能力增强，一个得到客户认可的产品会迅速的被传播，在客户群体数量稳定的情况下，不推出与之匹敌的产品，那么你的市场份额就会被抢占，这就导致业务需求变化速度较快，与之对应的，银行科技的系统研发能力也要具备快速迭代的能力，其硬件也要支撑产品快速上线。如果仍然保持着一个产品开发1年、测试1年、购买硬件上线部署1年的模式，那么贵企业的市场份额会迅速缩减，盈利降低甚至亏损。
容器的使用实现应用的标准化，实现开发/测试/生产环境一致性，保证统一的应用运行状态，实现应用标准化和环境一致性；通过弹性伸缩能力/应用高可用支持能力保障应用运行的稳定性；支持DevOps工具落地，支持CI/CD流水线，实现应用集成、交付、运维的全过程的流程化和自动化，加快应用发布频率，提升应用发布质量，实现应用迭代的敏捷性；通用微服务组件和中间件的集成和管理，完成自动部署、升级/回滚、弹性伸缩、运行监控、高可用性、安全性。
低响应延迟、高并发、高可用要求
打开一款APP软件，如果在3秒内无法得到响应，那么大部分客户会对使用这款软件失去兴趣；APP软件的使用降低地域限制的门槛，用户总量会大大增加；APP软件如果总是出现故障，客户也会失去使用的兴趣。
如果出现以上三种状况，企业产品将无人使用，企业就会失去市场。针对此类问题，就需要我们设计的产品、支撑的架构能够具备低响应延迟、支持高并发、支持高可用的特点。
处理复杂数据类型、大数据量要求
大数据、人工智能、5G等技术的进步正在产生大量的必须进行管理、存储和分析的数据，根据其形式又分为结构化数据、半结构化数据、非结构化数据。银行的账务被存储在关系型数据库中进行管理被称为结构化数据；银行系统产生的日志文件、办公邮件则是半结构化数据，银行业存取款、贷款等业务所产生的扫描文件、高拍仪拍摄的照片、理财业务录制的影像文件则被称为非结构化数据。在银监局监管要求与行内业务发展的推动下，数据会大量增加，如何处理复杂的数据类型、如何处理大量数据，这给我们的架构设计带来了极大挑战。
结构化数据仍然可以延用传统架构，使用关系型数据库处理，但是需要考虑大数据量的问题，那么非结构化数据呢？非关系型数据库、分布式架构给我们带来了福音，银行科技人员要了解这种数据库的技术原理、架构设计及部署实施，也要了解分布式架构的适用场景。
架构设计的转变，对应的运行维护也要有所转变，新形势下的运行维护又面临哪些问题哪？
管理对象增加、覆盖面增广
新旧架构体系的结合、过渡，监管要求的加强都导致我们需要维护的设备类型、设备量增大，增广，稳定性要求越来越高，人工巡检的方式不能及时的发现问题，防患于未然，这就需要使用自动化监控产品，而我们在过去多年的管理体验中发现，监控产品多了，但是相互之间没有关联，导致监控产品的增加并不能提升我们的运维效率。
一体化运维平台是解决困局的重要概念，但是如何打造适应本行系统运维需求的平台，这需要我们详细分析整体架构，分析业务重要程度，分析监管要求，选择合适的产品，并通过运维经验的积累，将各个监控系统进行关联，比如日志分析平台、软硬件监控平台相结合，将日志分析与主机告警相关联，在软硬件监控平台中统一告警，这样只需要关注一个展现页面就可以发现问题，又在排查问题的过程中获取有用的日志，加速问题的解决。
问题复杂，关联范围增加
超融合产品、分布式架构的运维对比传统架构的运维更具复杂性，要求运维人员不能仅仅具备一方面的能力，想要快速的解决问题，就需要既具备主机运维能力，又需要具有网络、存储等的处理能力，否则都是你查完主机，我排查网络，他再排查存储，然后再统合大家意见，做出判断，这样大大降低了问题解决效率，因此当前的运维人才是复合型的人才。
小结
互联网金融对传统银行造成极大的冲击，无论是业务模式，还是支撑其运行的科技体系，都在逼迫着银行进行转变，作为银行的科技人员也要在新时代中紧跟变革步伐，顺势而为。在“科技为业务服务”的宗旨下努力学习，积极探索，能守成，更懂变通，实现自我价值。原题：银行科技从业者对工作的思考：稳定安全不代表一成不变！ 如有任何问题，可点击文末阅读原文，到社区原文下评论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
推荐文章 · 点击阅读
辛酸运维路，运维工程师怎样才能在未来走得更好更远？写给转型阵痛期的银行 IT 人：在充满危机感的时代，永不言败！新时代下金融运维人的自我修养，不仅仅是技术基本功中小银行数字化转型过程中，集中架构环境下运维+架构人员如何转变？致金融科技人：转型到云生态环境中生存，这些不能不了解识别上方图中二维码阅读全部文章
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场